Authentication is the process of determining who a user (or entity) is. Authenticating user access for the PPP protocol on the 2212 extends the flexibility of user profile management as it relates to PPP authentication protocols PAP, MSCHAP, CHAP, and SPAP. See 'PPP Authentication Protocols' in Access Integration Services Software User's Guide for additional information about configuring PAP, MSCHAP, CHAP, and SPAP.
Authentication can be configured locally or can be configured to consolidate user configuration using authentication servers that are available on the network to service authentication requests for the entire network. The IBM 2212 implements locally maintained authentication as well as the following authentication server protocols:
Authentication, Authorization, and Accounting (AAA) Security are configurable protocols that allow you to control access to your services. You can configure AAA to perform for local or remote authentication.
You can configure a security protocol for three types of functions.
The configuring is done by setting a primary and secondary server. The server information is configured and stored separately from the AAA configuration. You use a server profile by a name that is provided at configuration time.
Under all circumstances accounting cannot be done locally and must be either Radius or TACACS+.
Authorization can only be done locally, or through remote authentication that uses Radius or TACACS+.
AAA Security is the name of the security system for this device. It includes:
For the Point-to-Point Protocol (PPP) you can configure the following:
Each function can have its own security protocol that you configure independently.
See Point-to-Point Configuration Commands in Access Integration Services Software User's Guide for details about the PPP configuration commands that you use in this environment.
The following are valid PPP security protocols:
Table 26. Set PPP Security Protocols
| Action | Authent | Author | Acct |
|---|---|---|---|
| set AAA local | local | local | ignore |
| set AAA remote | remote | remote | remote |
| set AUTHENT local | local | ignore | ignore |
| set AUTHOR local | ignore | local | ignore |
| set AUTHENT remote | remote | ignore | ignore |
| set ACCOUNTING local | n/a | n/a | n/a |
| set AUTHOR remote | ignore | remote | ignore |
| set ACCOUNTING remote | ignore | ignore | remote |
| disable ACCOUNTING | ignore | ignore | disabled |
| disable AUTHENT | n/a | n/a | n/a |
| disable AUTHOR | n/a | n/a | n/a |
For AAA login configuration, either remote or local can be selected. If local authentication is desired, then Local authorization must also be used. If remote authentication is selected, then, remote authorization must be used. accounting is not supported locally, so when authenticating and authorizing locally you must disable accounting.
| Attention: | Before enabling console login, save the configuration with console login disabled. If login authentication is set to a remote server using Radius, TACACS, or TACACS+ and the router is unable to reach the authentication server, then access to the router is denied. Disabling the console login prevents a lockout situation. |
When configuring remote authentication, you can set authorization to another remote authorization protocol Radius or TACACS+, and set accounting to use Radius or TACACS+.
The following are valid Login/Admin security protocols.
Table 27. Set Login Security Protocols
| Action | Authent | Author | Acct |
|---|---|---|---|
| set AAA local | local | local | disabled |
| set AAA remote | remote | remote | remote |
| set AUTHENT local | local | local | disabled |
| set AUTHOR local | local | local | disabled |
| set AUTHENT remote | remote | remote, if local else ignore | ignore |
| set AUTHOR remote | remote, if local else ignore | remote | ignore |
| set ACCOUNTING remote | remote, if local else ignore | remote, if local else ignore | remote |
| disable ACCOUNTING | ignore | ignore | disabled |
| disable AUTHEN | n/a | n/a | n/a |
| disable AUTHOR | n/a | n/a | n/a |
Set tunnel authentication the same as tunnel authorization. When you set tunnel authentication to either local or remote, you can then enable accounting. The tunnel authorization and authentication server must be the same.
The following are valid Tunnel security protocols:
Table 28. Set Tunnel Security Protocols
| Action | Authent | Author | Acct |
|---|---|---|---|
| set AAA local | local | local | ignore |
| set AAA remote | remote | remote | remote |
| set AUTHENT local | local | local | ignore |
| set Author local | local | local | ignore |
| set AUTHENT remote | remote | remote | ignore |
| set AUTHOR remote | remote | remote | ignore |
| set ACCOUNTING remote | ignore | ignore | remote |
| disable ACCOUNTING | ignore | ignore | disabled |
| disable AUTHENT | n/a | n/a | n/a |
| disable AUTHOR | n/a | n/a | n/a |
Local authentication allows you to use a password to control login access. The password can be checked against any or all of the following rules.
| Note: | The following rules only apply for PPP user login and not console login. |
An authentication server is a server in the network that validates userids and passwords for the network. If a device is configured for authentication through an authentication server and the device receives a packet from an authentication protocol, the device passes a userid and password to the server for authentication. If the userid and password are correct, the server responds positively. The device can then communicate with the originator of the request. If the server does not find the userid and password that it receives from the device, it responds negatively to the device. The device then rejects the session from which it got the authentication request.
The 2212 can authenticate dial-in clients that use SecurID with a Security Dynamics ACE/Server. This support uses TACACS, TACACS+, or RADIUS on the ACE/Server for authentication of the client. Configure the dial-in client the same as other dial-in clients on the 2212.
The dial-in client logs on as usual, but uses the SecurID passcode for the password. The SecurID passcode consists of a 4 to n-digit PIN number that is followed by the number from the SecurID token card. (The maximum number of digits in the PIN depends on the server.) The userid and password could appear as:
Figure 24. SecurID Username and Passcode
.--------------------------.
Username: | John Customer |
'--------------------------'
.--------------------------.
Password: | 1234098765 |
'--------------------------'
|
When the ACE/Server authenticates the logon, it may request the next token from the client. The next token is the next token on the token card. The maximum number of digits in the next token depends on the SecurID token card the client is using. The client can enter the passcode and the next token when prompted for the password by using the format passcode*token as in the following:
Figure 25. SecurID Passcode with Next Token
.----------------------.
Username: | John Customer |
'----------------------'
.----------------------.
Password: | 1234098765*111111 |
'----------------------'
|
| Note: | When the server requests the client to enter the next token, the client
must:
|
The ACE/Server administrator configures the conditions that cause the server to request the next token or new PIN.
The dial-in clients should use SPAP so they can receive alerts from the authentication system when they need to enter the next token. If the client is not using SPAP and they are not successful logging on, they should try entering a new passcode using the passcode*token format. If the client is still not successful, there could be other problems between the client and the ACE/Server.
The following limitations exist: